The dramatic increment of the demand by users of wireless communication systems for data services, like e-mail, file download, web browsing, multimedia streaming, etc., has made necessary an adequate response by the operators and industry. Known high-data rate packet transmission systems, like cdma2000, IMT-2000, 1XEV-DO, allow attaining downward data rates of up to 2.5 Mb/s.
A new system, named High-Speed Downlink Packet Access (HSDPA) for Wideband Code Division Multiple Access (WCDMA), has been developed by 3GPP (3rd Generation Partnership Project) to support data communications characterised by lower real-time demands than telephony services, higher data rates and asymmetric traffic, i.e. higher traffic volume in downlink direction than in uplink direction, as is for instance the case of file download and web browsing. The features of HSDPA have been defined in 3GPP Technical Specifications starting from Release 5. HSDPA has the following purposes and properties:
Data transmission in downlink direction only, i.e. from the Core Network (CN) via the Radio Network Control (RNC) to the subscriber;
Support of services from different Quality of Service (QoS) classes:                Background, e.g. file download, E-mail delivery, SMS etc.: lowest priority, low timing constraints, but preservation of payload contents (low bit error rate);        Interactive, e.g. web browsing, data base retrieval, server access, polling of measurement reports: higher traffic priority than background class traffic; end-to-end delay caused by HSDPA must be acceptable in a human- or machine-initiated request response pattern, i.e. it should not exceed a few seconds;        Streaming, e.g. video/audio streaming: guaranteed, but with variable bit rate; the transmission delay must not exceed a certain time (˜250 ms).        
The technological enhancements incorporated by HSDPA not only provide a spectral efficiency gain, but also support user data rates up e.g. to 8-10 Mb/s, i.e. rates about 4-5 times higher than e.g. the IMT-2000 (International Mobile Telecommunications 2000) requirements.
An important issue with HSDPA traffic is the timely detection of transport network layer congestion at the Iub/Iur interface, i.e. the interface between the RNC and the Node B or between a Serving RNC (SRNC) and a Drift RNC (DRNC), respectively. The external HSDPA flow control between the Node B and the RNC adjusts the Iub/Iur traffic flow to the available throughput at the air interface individually for each HSDPA traffic flow. It may happen that the capacity allocation messages from Node B to RNC result in a total capacity greater than the available Iub/Iur transport capacity, which often is not dimensioned according to the maximum air interface throughput since it is a very expensive resource. Under congestion conditions, packets at the physical and data link layers (e.g. ATM/AAL2 packets) could become lost and the Radio Link Control (RLC) layer has to initiate re-transmissions that significantly degrade the average throughput per HSDPA user.
Before the 3GPP enhancements included in Release 6 specifications, congestion detection (CD) was only based on the supervision of the payload of High Speed-Downlink Shared Channel Frame Protocol (HS-DSCH FP) data frames received at the Node B. Indeed, packet loss can cause loss of a portion of a FP Protocol Data Unit (PDU) payload that very likely is detected by the payload and/or header Cyclical Redundancy Code (CRC). A congestion detection only based on the CRC(s) has a twofold drawback: on the one hand it does not allow detecting congestion situations in advance, as the CRC check can only reveal that some data have already been lost; on the other hand, it does not allow detecting the loss of complete FP frames.
According to Release 6 enhancements, those drawbacks are overcome through the use of two new fields or Information Elements (IEs) defined in the FP frames of a data flow, namely the Frame Sequence Number (FSN) and the Delay Reference Time (DRT). Reference can be made to International Patent Applications WO-A 05/107293 and WO-A 05/104672, as well as to 3GPP Technical Specifications (TS) 25.402 “Synchronisation in UTRAN Stage 2”, 25.425 “UTRAN Iur interface user plane protocols for Common Transport Channel data streams”, 25.435 “UTRAN Iub Interface User Plane Protocols for Common Transport Channel data streams”, 3GPP Technical Report (TR) 25.902 “Iub/Iur congestion control”. Information about the current versions of those documents and the publication dates thereof can be found at the 3GPP site ww.3GPP.org.
Substantially, FSN is a 4-bit field incremented by the SRNC at each transmitted HS-DSCH FP data frame belonging to a specific data flow. DRT is a 16-bit field that represents the count of a counter that is locked to the RNC Frame Number Counter (RFN) in the Serving RNC (SRNC), i.e. the RNC which actually controls the radio connection, and that counts from 0 to 40959 ms with a 1 ms resolution. The DRT values are a kind of time stamp of the transmission instants for a given HS-DSCH FP data frame.
Field FSN can be used by the Node B to estimate the packet loss rate, whereas field DRT can be used by Node B for dynamic delay measurements. Field DRT allows the Node B to detect in advance that congestion situations are about to occur, so that the Node B can timely request a reduction of the throughput on the Iub/Iur interface to the SRNC; on the other hand, if congestion occurs, the FSN field allows reducing to a minimum the impacts on the traffic, i.e. data losses.
Also a congestion management exploiting the FSN/DRT fields still gives rise to some problems.
In case of HSDPA, congestion management is an exclusive task of the Node B. There can be cases where the consistency of the received DRT and FSN values cannot be guaranteed at the Node B. An example is represented by Core Network procedures such as for instance SRNC relocation. Here the SRNC changes and the values of DRT and FSN transmitted to the Node B by the new SRNC are no longer consistent with those previously transmitted by the old SRNC, since the DRT and FSN values from different RNCs are generally locked to different RFNs, which inevitably exhibit a phase difference. Another possible inconsistency could result from a temporary impossibility for the SRNC to access the RFN. A discontinuity in the received DRT and FSN values would be attributed by the Node B to a congestion situation on the transport network and therefore it would trigger a reduction of the downlink Transmission Credits granted to the SRNC, which is in fact unmotivated. This will result in a decrease of the average throughput in the downlink direction and hence in a worsening of the QoS. In the worst case, all measurements performed by the Node B after the SRNC relocation could be affected.
More in general, it can be useful for the SRNC to have the possibility to temporarily suspend the DRT and FSN based TNL measurements at the Node B for some HSDPA flows for a defined time interval. This would additionally allow the SRNC to do a sort of temporary traffic priority handling, e.g. implicitly assigning higher priority (at TNL level) to those HSDPA data flows whose DRT and FSN based measurements have been suspended.
Currently there is no way for the transmitting side (i.e. the SRNC) to inform the receiving side (i.e. the Node B) of this situation. To avoid wrong measurements at the Node B, the SRNC could suspend the transmission of the DRT field for a given time interval, such that the Node B memory for the DRT measurements gets reset. However, such a procedure cannot be applied to the FSN field, as there is no possibility offered by the standard to suspend FSN transmission.